See #98 (comment); I think it's reasonable to impl ConditionallySelectable for Ordering in its own change here, but I think we should avoid impling ConstantTime{Eq,Less,Greater} for Ordering (see linked comment).

I'll note that #98 would also have very cleanly fixed https://github.com/RustCrypto/crypto-bigint/pull/159/files/d4d99aa7599123cdbb6e4c341bba7b7061e84f8b#r1066410790, which also hand-generates an Ordering instance. While I agree with your goal of separating the {Partial,}Ord traits from the ConditionallySelectable impl in #98, I think that impling ConditionallySelectable for Ordering is only useful for providing ConstantTime{Partial,}Ord.

If we want to slim down #98 more, I could try removing ConstantTimePartialOrd from it for now; that would allow us to address both libsignal and crypto-bigint's use cases cleanly without getting into the weeds of partial orders yet.

Please confirm: I cannot see how implementing ConstantTime{Eq,Less,Greater} for Ordering can be used to implement ConstantTime{Partial,}Ord! The Ordering (or CtOption) instance cannot be created without the ConstantTime{Partial,}Ord traits in this PR. Is this correct?

No, I already had a code solution here:

https://github.com/RustCrypto/crypto-bigint/pull/159/files/d4d99aa7599123cdbb6e4c341bba7b7061e84f8b#r1064244105

However it would need the changes in this PR to compile.

It's pretty much the same one I suggested here:

#98 (comment)

I think having ConstantTime{Partial}Ord would still separately be useful, because it could be impl'd for core types much in the same way traits like ConstantTimeEq and ConditionallySelectable are impl'd for core types.

Separately, I don't see how you consume a returned Ordering without branching without this PR, especially in cases where you want to compare two or more orderings.